Peer-To-Peer Payment Processing

ABSTRACT

Systems and related methods facilitating payments with a mobile device are discussed herein. Circuitry in a networked-based payment system may be configured to receive payment information from a first device. The first device may include circuitry configured to wirelessly receive wallet identifying data from the payment system. The wallet identifying data may be used to secure messages between the first device and another device over a wireless link. For example, the first device may be configured to send the wallet identifying data to a second device, which may then communicate with the payment system. In response, consumer identifying data associated with the wallet identifying data may be received by the second device from the payment system. In some embodiments, use of wallet identifying data may be applied to other communications, such as for messages that authorize payment.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 61/715,229, entitled “Peer-To-Peer Payment Processing,”filed Oct. 17, 2012, which is incorporated herein by reference in itsentirety.

FIELD

Embodiments of the invention relate, generally, to facilitating paymentsvia a mobile device.

BACKGROUND

Financial transactions between merchants and consumers typically requirethe consumers to present a form of payment to the merchant. As a result,consumers may be required to keep wallets that include cash, creditcards, debit cards, checks or other payment instruments that may beaccepted by merchants and/or their devices used at the point-of-sale(e.g., point-of-sale devices, such as cash registers, credit cardreaders, etc.). In this regard, areas for improving current systems havebeen identified. Through applied effort, ingenuity, and innovation,solutions to improve such systems have been realized and are describedin connection with embodiments of the present invention.

BRIEF SUMMARY

Systems, methods, and computer readable program code are provided to, ingeneral, improve payment using a device. More specifically, embodimentsprovided herein may include a payment system that may be implemented toprovide merchants (e.g., those that have “brick-and-mortar” retail spaceand/or online ordering storefronts and/or peers that receive payment) away to receive payment from a consumer based on data sent (e.g.,automatically, in some embodiments) by a consumer's machine and withoutthe consumer having to present any payment account information orcurrency directly to the merchant (or peer).

Some embodiments may provide for a merchant (or peer) device thatincludes a display configured to present interactive displays,communications circuitry configured to facilitate communications with aconsumer (or peer) device and a payment system, and processingcircuitry. The processing circuitry may be configured to: wirelesslysend a total cost to the consumer device; wirelessly receive consumerapproval data for a payment_secured with wallet identifying data fromthe consumer device; and send the consumer approval data secured withthe wallet identifying data to the payment system.

In some embodiments, the wallet identifying data may be based at leastpartially on a random code generated by the payment system. The walletidentifying data may include one or more tokens and/or keys.Furthermore, the consumer approval data may include data that isencrypted, signed, or otherwise secured with the wallet identifyingdata.

In some embodiments, the processing circuitry of the merchant device maybe further configured to: receive a payment confirmation indicatingpayment of the total cost from a payment account associated with theconsumer device; and send a receipt indicating payment of the total costto the consumer device.

In some embodiments, the processing circuitry of the merchant device maybe further configured to receive, from the payment system, consumeridentifying data associated with the wallet identifying data.

In some embodiments, the processing circuitry of the merchant device maybe further configured to receive, from the payment system, consumeridentifying data associated with the wallet identifying data.

In some embodiments, the processing circuitry of the merchant device maybe further configured to: receive product identifying data, whereinprice data is associated with the product identifying data; anddetermine the total cost based on the price data.

In some embodiments, the processing circuitry of the merchant device maybe further configured to receive image data representing a picture of aconsumer associated with the consumer device. For example, the imagedata may be received from the payment system in response the consumerdevice coming within communicable range with the merchant device. Insome examples, the image data may be received prior to sending the totalcost to the consumer device.

In some embodiments, the processing circuitry of the merchant device maybe further configured to establish a connection with the consumer devicevia a personal area network. For example, the personal area network maybe configured to communicate via one or more Bluetooth protocols. Themerchant device may be further configured to wirelessly receive theconsumer approval data secured with the wallet identifying data from theconsumer device over the personal area network even when the merchantdevice and/or consumer device lacks Internet access and is unable toconnect to the payment system

Some embodiments may provide for a consumer (or peer) device thatincludes a display configured to present interactive displays,communications circuitry configured to facilitate communications with amerchant (or peer) device and a payment system, and processingcircuitry. The processing circuitry may be configured to: receive walletidentifying data from the payment system; wirelessly receive a totalcost from the merchant device; wirelessly send consumer approval datasecured with the wallet identifying data to the second device; andreceive a receipt indicating payment of the total cost from the paymentprocessing system.

Some embodiments may provide for a payment system that includes anetworked device (e.g., a payment server). The networked device mayinclude communications circuitry configured to facilitate communicationswith a consumer device and a merchant device and processing circuitry.The processing circuitry may be configured to: send wallet identifyingdata to a consumer device; receive consumer approval data associatedwith a payment secured with the wallet identifying data from a merchantdevice; validate the consumer approval data received from the merchantdevice; and process the payment after validating the consumer approvaldata received from the merchant device.

In some embodiments, the processing circuitry of the networked devicemay be further configured to: receive consumer identifying data from theconsumer device; receive payment account information from the consumerdevice; and generate the wallet identifying data associated with thepayment account information and the consumer identifying data. In someembodiments, the processing circuitry of the networked device may befurther configured to generate random code and generate the walletidentifying data based at least partially on the random code.

Some embodiments may include methods that may be computer-implemented byone or more of the machines discussed herein. Other embodiments mayinclude one or more machines, such as an apparatus and/or system,configured to implement the methods and/or other functionality discussedherein. For example, the machine may include one or more processorsand/or other machine components configured to implement thefunctionality discussed herein based on instructions and/or other datastored in memory and/or other non-transitory computer readable media.

These characteristics as well as additional features, functions, anddetails are described below. Similarly, corresponding and additionalembodiments are also described below.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described some embodiments in general terms, reference willnow be made to the accompanying drawings, which are not necessarilydrawn to scale, and wherein:

FIG. 1 shows a flow chart of an example method for facilitatingtransactions, performed in accordance with some embodiments;

FIG. 2 a shows a flow chart of an example method for accessing a paymentaccount, performed in accordance with some embodiments;

FIG. 2 b shows a flow chart of an example method for creating a paymentaccount, performed in accordance with some embodiments;

FIGS. 3-12 show example graphical user interface displays that may bepresented by various components of systems, in accordance with someembodiments;

FIGS. 13 and 14 show flow charts of example methods for facilitatingtransactions, performed in accordance with some embodiments;

FIGS. 15-22 show example graphical user interface displays that may bepresented by various components of systems, in accordance with someembodiments;

FIG. 23 shows an example graphical user interface display that may bepresented by various components of systems, in accordance with someembodiments;

FIG. 24 shows a flow chart of example methods for providing offers,performed in accordance with some embodiments.

FIG. 24 shows an example system for providing payments and promotionaloffers, configured in accordance with some embodiments; and

FIG. 25 shows an example schematic block diagram of circuitry,configured in accordance with some embodiments.

DETAILED DESCRIPTION

Embodiments now will be described more fully hereinafter with referenceto the accompanying drawings, in which some, but not all embodiments areshown. Indeed, embodiments of the invention may be implemented in manydifferent forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will satisfy applicable legal requirements. Likenumbers refer to like elements throughout.

As used herein, the terms “data,” “content,” “information” and similarterms may be used interchangeably to refer to data capable of beingcaptured, transmitted, received, displayed and/or stored in accordancewith various example embodiments. Thus, use of any such terms should notbe taken to limit the spirit and scope of the disclosure. Further, wherea computing device is described herein to receive data from anothercomputing device, it will be appreciated that the data may be receiveddirectly from the another computing device or may be received indirectlyvia one or more intermediary computing devices, such as, for example,one or more servers, relays, routers, network access points, basestations, and/or the like. Similarly, where a computing device isdescribed herein to send data to another computing device, it will beappreciated that the data may be sent directly to the another computingdevice or may be sent indirectly via one or more intermediary computingdevices, such as, for example, one or more servers, relays, routers,network access points, base stations, and/or the like.

Overview

Embodiments discussed herein may be configured to provide payments via amobile device (e.g., a consumer device). In this regard, someembodiments may free a consumer from having to carry any traditionalpayment instructions, such as credit cards, currency, checks, and/orother items typically stored in a physical wallet. Instead, the consumermay associate a payment account with the consumer device, such as amobile phone, and make payments from the payment account simply bycarrying and/or using the consumer device. For example, rather than handa credit card and/or other tangible form of payment to a merchant or apeer (e.g., a second consumer or the like), the consumer device may beconfigured to provide (e.g., automatically and/or in response toreceiving a user indication to do so) wallet identifying data thatfacilitates a payment of a certain amount to the merchant by a networkedsystem.

Another advantage that may be realized by some embodiments discussedherein allows for secure payments, whether the payments are between aconsumer device and a merchant device, two consumer devices or twomerchant devices. As such, consumers and merchants may be protected fromunauthorized devices and/or fraudulent payments.

Yet another advantage that may be realized by some embodiments discussedherein is that the consumer device and/or merchant device can beconfigured to facilitate a network-based payment without an activeconnection with the payment system (e.g., via the Internet) at the timeof the transaction. For example, when a consumer device enters thevicinity of or is otherwise within communicable range (sometimesreferred to herein as being “in proximity”) with a compatible merchant(or peer) device, a connection (e.g., via a personal area network(“PAN”)) may be automatically created. Despite the lack of an activeconnection to the payment system, the consumer device and/or merchantdevice may make secure payments by sharing the wallet identifying datavia the connection. The wallet identifying data may be stored and latersent to the payment system for additional processing (e.g., to completea financial transaction). Some other, but non-exhaustive, advantagesthat may be realized by some embodiments discussed herein includeallowing a merchant/peer to ensure that the consumer device user is infact the real person authenticated to the consumer device, allowingpayments between two peer devices, providing promotional offerings(e.g., promotional vouchers, sales, discounts, rewards, or the like) tothe consumer, and/or facilitating consumer service and point-of-salefunctionality.

Facilitating Financial Transaction Overview

FIG. 1 shows a flow chart of an example method 100 for facilitatingtransactions, in accordance with some embodiments. Method 100 is meantto show a high level example, while some of the other processes flowsdiscussed herein (such as those discussed in connection with FIGS. 13and 14) show more detailed examples.

At 102, a payment system may be configured to send wallet identifyingdata to a consumer device. For example, a consumer may be associatedwith a payment account that is accessed via the consumer device. Uponaccessing the payment account via the consumer device (e.g., providinglogin data), the payment system may send the wallet identifying data tothe consumer device.

The wallet identifying data can comprise, for example, one or more keys,numbers, codes, and/or other types of tokens that are randomly orotherwise generated and/or assigned. “Random,” as used herein, mayinclude pseudorandom and/or random generation and assignment schemes.The wallet identifying data may be used to encrypt, sign, and/orotherwise secure messages. As such, private information such as consumerdata, merchant data, financial data, transaction data, and/or othersensitive, non-random data may be secured with the wallet identifyingdata.

For example, the wallet identifying data may be random data associatedwith the more sensitive, less random data, and the wallet identifyingdata can be transmitted over at least some types of communication links(e.g., unsecured or less secured wireless networks or directconnections) instead of the more sensitive, less random data. In someembodiments, a recipient, such as an authorized merchant device, can beconfigured to receive the wallet identifying data, communicate thewallet identifying data to a payment processing system (which may becloud-based), and receive the sensitive data securely (or at least moresecurely). For example, the wallet identifying data may provide themerchant device with access to consumer information via the paymentsystem in some embodiments. In some embodiments, the wallet identifyingdata may include a wallet identifying token and a private key. Thewallet identifying token may be configured to be passed to other devices(e.g., a consumer device, a merchant device, a central system, etc.) tovalidate or authenticate various types of data. For example, the walletidentifying token may be passed to the merchant device, where themerchant device may be configured to share the wallet identifying tokenwith the payment system to receive consumer information.

The private key may be used by the central system to correlate a walletidentifying token with consumer identifying data and to validate and/orotherwise verify secured payment approval data such that the data may berelied upon as authentic and, thus, processed or otherwise used. Theprivate key may be kept secret by the central system and/or securelyshared with only devices (e.g., consumer devices) authorized to usewallet identifying tokens and private keys. In some embodiments, awallet identifying token and a corresponding private key may begenerated together and/or mathematically related such that determiningthe private key from the wallet identifying token (and vice versa) isvery difficult, if not impossible, and extremely time consuming orprohibitively expensive.

After receiving the wallet identifying data at 102, the consumer maywalk into a store while carrying the consumer device. The consumerdevice may be configured to connect with a merchant device, such as viaa personal area network (e.g., using Bluetooth) when the consumer devicecomes within a communicable range to a merchant device. In someembodiments, the consumer device and the merchant device may communicatevia the connection and perform payments without requiring that theconsumer device have an active connection to the payment system (e.g.,via the Internet). After picking out items for purchase, the consumerdevice may receive transaction data (which may include or be limited to,among other things, a total cost of the items) from the merchant deviceand/or from one or more input components coupled thereto (e.g., abarcode scanner, magnetic stripe reader, user keypad, touchscreendisplay, etc.).

The discussion herein regarding merchant devices may also be applicableto a peer device, such as a second consumer device. For example, theconsumer device may be configured to connect with the second consumerdevice, such as via the PAN when the consumer device comes within acommunicable range to the second consumer device. As such, a “merchantdevice,” as used herein, may refer to a second consumer device that isconfigured to receive payments from the consumer device.

At 104, the consumer device may be configured to send consumer approvaldata with the wallet identifying data to the merchant device. Theconsumer approval data may indicate, among other things, that theconsumer approves a payment as indicated by the transaction data. Inembodiments where the wallet identifying data includes a private key,the consumer approval data may include transaction data that is signedor otherwise secured using the private key. As such, the consumerapproval data may be secured with the wallet identifying data and sentto the merchant device.

In some embodiments, the consumer device may be configured toautomatically send the consumer approval data automatically uponreceiving the transaction data. For example, one or more merchants canbe associated with a pre-approved list, a per-transaction cost thresholdcan be set for preapproval (e.g., all transactions under $20 can beautomatically approved by the consumer device), a per-day cost threshold(e.g., up to $100 per day can be automatically approved), and/or anyother variable(s).

At 106, the merchant device may be configured send the consumer approvaldata secured with the wallet identifying data to the payment system. Insome embodiments, the merchant device may be further configured togenerate secured payment approval data and to send the secured paymentapproval data to the payment system. The secured payment approval datamay be a combination or other association of the consumer approval dataand the transaction data. The payment system may use this information todetermine whether to approve the payment by the consumer (e.g., via thepayment account). In some embodiments, the payment system may beconfigured to validate the consumer approval data. For example, thepayment system may be configured to compare the wallet identifying datareceived from the merchant device at 106 with the wallet identifyingdata sent to the consumer device at 102. If the payment system approvesthe payment, a payment confirmation may be sent to the merchant deviceat 108.

In some embodiments, the transaction receipt (e.g., information aboutthe particular transaction) and/or other receipt information may be sentto the consumer device from the payment server at 110A. The otherreceipt information can include, for example, a remaining balance and/orpurchase power after the instant transaction (e.g., the amount of moneyuntil the consumer's account reaches the applicable credit limit(s), theamount of money remaining in the consumer's debit account after thetransaction is processed, etc.), total spend over a given period of time(e.g., the amount of money spent in an hour, day, week, etc. includingthe instant transaction), total spend at a given merchant and/orlocation (e.g., amount of money spent at the merchant over a period oftime, amount of money spent in a city over a period of time, etc.),and/or any other purchase-related information that may be of interest tothe consumer subsequent to a transaction (including information that mayhelp identify fraud and/or improper use of the consumer's paymentaccount).

In addition to or instead of the receipt being sent from the paymentserver to the consumer device at 110A, a transaction receipt and/orother receipt information may be sent to the consumer device from themerchant device at 110B. The receipt information sent from the merchantdevice can be the same as or different than that sent at 110A, and/orcan be independent of or based on receipt information generated by theprocessing server. For example, the merchant device can be configured tosend an independent receipt to the consumer device that the consumer canuse to verify the receipt information sent from the payment processingsystem at 110A. For example, this may aid the consumer in confirmingthat the payment processing system actually charged the consumer'spayment account the amount the merchant indicated was due for thegoods/services purchased (and/or help the consumer identify adiscrepancy between what was purchased and the amount actually chargedby the payment processing system). As another example, the paymentserver may also or instead send receipt information to the merchantdevice, which may then send the receipt to the consumer device.

FIG. 2 a shows a flow chart of an example method 200 for accessing apayment account, performed in accordance with some embodiments. Method200 will be described with reference to example displays 300-1200 shownin FIGS. 3-12, respectively.

FIGS. 3-12 show example displays 300-1200 that may be presented by oneor more display screens of one or more machines, such as those used byconsumers, which are sometimes referred to herein as “consumer devices,”in accordance with some embodiments discussed herein. For example, thedisplays may be presented to a consumer (e.g., a user that makespayments) by a mobile device and/or a stationary device. Example mobiledevices may include a cellular telephone (including smart telephonesand/or other types of mobile telephones), laptop, tablet, and/or thelike. Additionally or alternatively, a consumer may access displays300-1200 and 1400-2200 via a stationary device, such as a desktopcomputer, work station, POS device, and/or any other type of device.FIGS. 15-22 are additional example displays, namely displays 1500-2200,which may be presented by one or more display screens included in one ormore consumer devices.

FIG. 23 shows an example display 2300 that may be presented by one ormore display screens of one or more machines, such as those used bymerchants, sometimes referred to herein as “merchant devices.” Anynumber of staff members employed by a merchant may have access tomerchant devices, and, as such, the term “merchant” is sometimes usedherein to describe any user representing the merchant and/or any otherperson who receives payment from another person, namely the consumer.Like consumer devices, merchant devices may include stationary devicesand/or mobile devices. Additional examples of merchant devices andconsumer devices are discussed in connection with FIGS. 24 and 25.

In some embodiments, any physical device may be configured to performthe functionalities described herein with respect to both merchantdevices and consumer devices. For example, a device may be configured tomake a payment (e.g., like a consumer device) and also receive a payment(e.g., like a merchant device).

In some embodiments, the displays 300-1200, 1500-2200 and 2300 may beaccessed via an application that executes locally and causes amerchant/consumer device to be configured to function as a specializedmachine. Additionally or alternatively, cloud-based, multi-tenant,thin-client, and/or other types of online service techniques may beused. For example, the displays may be provided by one or moreapplications that execute on a remote device, such as a server and/orother networked machine. User input information may be generated by andsent from the merchant/consumer device to the remote device, whilevisual and/or audio information is sent from the remote device to thedevice.

Turning back to FIG. 2 a, method 200 shown therein may start at 202 andproceed to 204, where a payment system (e.g., payment server 2404 shownin FIG. 24) may provide a login display to a consumer device. Forexample, FIG. 3 shows login display 300 that may be displayed by/to aconsumer device (e.g., consumer device 2412 shown in FIG. 24). Logindisplay 300 may be accessed by virtually any method, such as anapplication executed by the consumer device. Alternatively and/oradditionally, login display 300 may be accessed via a web browser, suchas by entering an address (e.g., a uniform resource locator (“URL”)address) into the web browser's location bar. Login display 300 may beconfigured to allow a user to create a payment account and/or sign in toa payment account. As such, login display 300 may include create accountselection 302 and sign in selection 304.

At 206, the payment system may be configured to determine whether theconsumer has provided login data for the payment account. For example,the consumer may select sign-in selection 304 in login display 300 toindicate a desire to sign-in with a preexisting payment account. Inresponse, the consumer device may be configured to accept login data(e.g., a username, password, biometric identifier, etc.) for the paymentaccount. For example, login input display 400, as shown in FIG. 4, maybe configured to accept the login data in some embodiments. The consumermay enter a username to username field 402, a password to password field404, and submit the payment (e.g., to the one or more servers) byselecting login selection 406.

If the consumer provides login data at 206, method 200 may proceed to208. At 208, the payment system may be configured to determine whetherthe login data is valid. For example, the login data received from theconsumer device may be compared with login data stored in one or moredatabases (e.g., payment database 2402 shown in FIG. 24).

In some embodiments, the payment system may be configured to determinewhether the consumer has provided third party login data for a thirdparty account. For example, the consumer may select third party loginselection 408 in login input display 400, which may allow the user toenter the third party login data (e.g., a username and password for thethird party account).

The third party account may be any type of account that is provided byone or more third party servers (e.g., third party system 2412 shown inFIG. 24). As will be discussed in greater detail with respect to FIG. 2b, the consumer may associate one or more third party accounts with thepayment account, allowing the consumer to access the payment account viathe third party account (e.g., by logging in and/or otherwiseauthenticating with third party login data). Example third partyaccounts may include an email account, a social networking account, anaccount provided by a merchant, a banking account, etc.

If the consumer provides the third party login data, a determination maybe made as to whether the third party login data is valid at 208. Forexample, the payment system may be configured to send the third partylogin data to an appropriate third party server/system (e.g., with alogin request). The payment system may be further configured to receivean indication regarding whether the login data is valid or invalid inresponse. As such, some embodiments may allow the consumer to access thepayment account via one or more different third party accounts andassociated third party login data.

If the login data is determined to be valid at 208, method 200 mayproceed to 210, where the payment system may be configured to provideaccess to the payment account. As will be discussed in greater detail,the consumer device may be configured to, among other things, makepayments via the payment account, associate one or more payment sourceswith the payment account, and/or view receipts of payments afterreceiving access to the payment account.

If the login data is determined to be invalid at 208, method 200 mayreturn to 206 where a determination may be made as to whether theconsumer wants to make another attempt at providing login data for thepayment account. In some embodiments, the payment account (e.g., asidentified by username field 202) may be locked out after a certainnumber of unsuccessful login attempts.

Returning to 206, if the consumer does not provide login data, method200 may proceed to 212. At 212, the payment system may be configured toallow the consumer to create a payment account. As discussed above, theconsumer may select create account selection 302 at login display 300.Responsive to the selection, the payment system may be configured toprovide interfaces (e.g., displays 500-1200 shown in FIGS. 5-12) to theconsumer device for creating the payment account, which will bedescribed in further detail with respect to example method 220 shown inFIG. 2 b. After creating the payment account, the consumer device may beallowed to access the payment account using method 200. Method 200 mayend at 214.

FIG. 2 b shows a flow chart of an example of a method 220 for creating apayment account, performed in accordance with some embodiments. Method220 may begin at 222 and proceed to 224, where login data (e.g., ausername and password) for the payment account may be received from theconsumer device. FIG. 5 shows an example create account display 500 thatmay be presented by the consumer device. Create account display 500 mayinclude name field 502, email address fields 503, and password field504. In some embodiments, an email address entered into email addressfields 503 may be used as the username for the payment account (e.g., atusername field 402, as shown in FIG. 4). Alternatively and/oradditionally, the consumer may enter a username that is different fromthe email address that may be used for login. The consumer device may beconfigured to send the login data to the one or more servers responsiveto the consumer selecting continue selection 508.

At 226, the login data received from the consumer device may beassociated with a payment account. For example, associations between thelogin data may be stored in the one or more databases (e.g., paymentdatabase 2406 shown in FIG. 24). As such, the consumer may provide thelogin data to receive access to the payment account and/or associateddata.

At 228, image data representing a picture of a consumer may beassociated with the payment account. For example, the consumer devicemay be configured to display add photo display 600 responsive to theconsumer selecting continue selection 508 in create account display 500.In some embodiments, the consumer device may include and/or otherwise beconfigured to control an image capturing device. The image capturingdevice may be any device configured to be able to capture the imagedata, such as a camera, a webcam, video recorder, etc. As such, theconsumer device may be configured to allow the consumer to capture theimage data by selecting take picture selection 602. Additionally and/oralternatively, the consumer may be allowed to choose existing image data(e.g., an image taken at an earlier time and stored) for associationwith the payment account, such as by selecting upload image selection604.

FIG. 7 shows an example confirm photo display 700 that may allow theconsumer to review captured and/or existing image data, in accordancewith some embodiments. For example, the image data may be shown atconsumer image display 702. If the image data is unsatisfactory, theconsumer may select retake selection 704. In some embodiments, theconsumer device may be configured to display add photo display 600 inresponse. If the image data is satisfactory, the consumer may select usephoto selection 706. The consumer device may be configured to send theimage data to the one or more servers responsive to the selection.

Returning to FIG. 2 b, at 230, the one or more servers may be configuredto associate one or more payment sources with the payment account. Insome embodiments, a payment source may be a financial payment account,such as a credit account, a checking account, a debit account, a thirdparty payment account, a savings account, a bank account, or the like.In that sense, a “payment source,” as used herein, may refer to any typeof account capable of being associated with a currency balance (e.g.,dollars, credits, etc.), providing a payment that decreases the balance,and/or receiving a payment that increases the balance.

FIG. 8 shows an example add payment source display 800 that may allowthe consumer device to send the one or more payment sources to the oneor more servers, in accordance with some embodiments. The consumer mayenter a name and billing address at 802 and 804, respectively. Theconsumer may further select enter credit card selection 806, which mayallow the consumer to enter a credit card as a payment source. It isappreciated that credit cards and/or credit card account numbers areonly an illustrative example, and that the techniques disclosed hereinmay be applicable to other types of payment sources, including checkingaccount numbers, debit account numbers, savings account numbers, and/orany other account number that may have value and/or a value associatedtherewith to be used for payment.

Upon selecting enter credit card selection 804, the consumer device maybe configured to allow a user to scan a credit card. For example, aconsumer may hold a credit card to an image capturing device that may beconfigured to capture the credit card as image data, as shown in creditcard capture display 900 in FIG. 9. The image data may be processed(e.g., using optical character recognition (“OCR”) to extract a creditcard number, expiration date and/or credit verification value (or“CVV”). One example of software that may provide credit card capturingand data extraction with a mobile device camera is card.io. It isappreciated, however, that any technique for reading credit card datamay be used. For example, a barcode reader device that may read creditcard data when the consumer swipes a credit card through the magneticstripe reader device may be used in addition, or alternatively, to theimage capturing device.

Additionally and/or alternatively, the consumer may select entermanually selection 902, which may cause the consumer device to displaymanual entry display 1000, as shown in FIG. 10. The consumer may enter acredit card number at 1002, the expiration date at 1004, and the CVV at1006. In some embodiments, extracted credit card data from the imagedata may be used to automatically populate these fields, allowing aconsumer to correct any mistakes (e.g., an OCR error). The consumer mayreturn to credit card capture display 900 via camera selection 1008. Theconsumer may also submit the entered credit card data by selectingsubmit selection 1010.

FIG. 11 shows an example confirm payment source display 1100, inaccordance with some embodiments. Confirm payment source display 1100may be shown, for example, after the payment system has validated thecredit card data. The consumer may add a payment source and/or replacethe credit card data with a different payment source, such as byselecting change card selection 1110. The consumer may also indicatethat the name at 1102, billing address at 1104, and/or credit card dataat 1106 is correct by selecting continue selection 1108.

Returning to FIG. 2 b, at 232, the payment system may be configured tomake a determination as to whether to associate one or more third partyaccounts to the payment account. In some embodiments, connecting a thirdparty account may allow a user to login to the payment account via thethird party account, as discussed above at 206 of method 200.Additionally and/or alternatively, third party account data (e.g., userprofile, purchase history data, social network data, etc.) may be usedto generate tailored recommendations for products, services, merchants,discounts, promotional vouchers, or the like that may be presented tothe consumer device. For example, the consumer may use third partyaccount connection display 300 associate a third party account (e.g., asocial network account) by selecting connect account selection 1202.

At 234, the consumer device may be configured to prompt the consumer forthird party login data, which may be received by the payment system. Thepayment system may be configured determine whether the login data isvalid at 236, which may include contacting a third party system/server.If the login data is valid, method 220 may proceed to 238, where thethird party account may be associated with the payment account. If thelogin data is invalid, method 220 may return to 232, to determinewhether the user is still interested in connecting a third partyaccount. If the consumer is not interested in associating a third partyaccount with the payment account at 232, method 220 may end at 240.Returning to FIG. 12, the payment system may be configured to provideaccess to the payment account, associated data, and/or functionalityresponsive to the consumer selecting go to application selection 1204.

Payments Via Consumer Device

FIG. 13 shows a flow chart of an example data flow represented by method1300, which can result in facilitating a payment and/or othertransaction, performed in accordance with some embodiments. Method 1300is described as being performed by a consumer device (e.g., consumerdevice 2412 shown in FIG. 24), a merchant device (e.g., merchant device2410) and a payment system (e.g., one or more networked machines and/orpayment server 2406). However, similar techniques may be applicable topayments between two peer devices (e.g., where a second consumer deviceacts like a merchant device as discussed herein).

In some embodiments, method 1300 may be performed after the consumerdevice has logged in or otherwise authenticated with the payment systemto access a payment account. Method 200 for creating the payment accountmay be performed with a consumer device that is different from thedevices that are configured to send payments as referenced in connectionwith methods 100, 1300 and 1400 of FIGS. 1, 13 and 14, respectively.

At 1302, the payment system may be configured to send wallet identifyingdata to the consumer device. As such, the consumer device may beconfigured to store the wallet identifying data. “Wallet identifyingdata,” as discussed above, may refer to any type of data that may beused to secure data transfers between the consumer device and themerchant device while still enabling the consumer device to cause themerchant device to receive secure information about the consumer (and/orthe consumer's payment account) from the payment system. For example,the wallet identifying may include, or may be based at least partiallyon, a random code generated by the payment system that is associatedwith the payment account of the consumer. In some embodiments, eachpiece of wallet identifying data sent to the consumer device at 1302 mayinclude a wallet identifying token and an associated private key.

In some embodiments, some or all of the messages sent by the consumerdevice to the merchant device may be encrypted with and/or be signedwith the wallet identifying data. The wallet identifying data and/ormessages encrypted with wallet identifying data, if intercepted orotherwise downloaded by an unauthorized device, will not reveal consumerdata, merchant data, financial information, and/or content of messagesin some embodiments. Furthermore, messages that are signed with thewallet identifying data (e.g., the wallet identifying data, such as theprivate key, is appended or otherwise included with the message) may beused to identify the message sender and/or to authenticate the messagesender (e.g., to prove that the sender is the identified correctly). Insome embodiments, some or all of the messages sent by the merchantdevice to the consumer device may be encrypted and/or signed withmerchant identifying data. Merchant identifying data may include, or maybe based at least partially on, a random code generated by the paymentsystem that is associated with an account (e.g., a payment account, bankaccount, credit card account, savings account, etc.) of the merchant.

In some embodiments, the wallet identifying data may be used for sendingconsumer data, identifying the payment account associated with theconsumer device, signing messages by the consumer device thatdemonstrate consumer consent (e.g., for a payment) and/or proving theauthenticity of the message, and/or encrypting messages to ensure thatthe messages remain secure. The wallet identifying data may in someexample embodiments include one or more tokens generated by the paymentsystem. Furthermore, the wallet identifying data may be sent to theconsumer device at virtually any time. For example, wallet identifyingdata may be sent to a consumer device when the consumer creates apayment account via the consumer device, logs in to the payment accountvia the consumer device, on a scheduled basis (e.g., each day, eachhour, each month, etc.), in the course of a transaction, or the like.

At 1304-1308, the consumer device and the merchant device may beconfigured to form a connection. In some embodiments, the connection maybe formed without the consumer device and/or the merchant device havingactive Internet access at the time of the connection (e.g., an activeconnection to the one or more public servers). For example, theconnection may be a wireless connection over a personal area network(e.g., via PAN network 2416 shown in FIG. 24). Some suitable personalarea network protocols may include Bluetooth, Infrared Data Association(irDA), wireless USB, ZigBee, WiFi, and Z-Wave. It is appreciated,however, that any other type of connection between the consumer deviceand merchant device, such as direct wire, Internet, near fieldcommunications and/or radio frequency identification technologies, maybe used.

Depending on the protocol used, at 1304, the consumer device may beginannouncing a payment service to other devices, such as the merchantdevice. For example, a process and/or application may execute on andconfigure the consumer device to broadcast (e.g., via Bluetooth) one ormore suitable messages. FIG. 15 shows an example payment service menudisplay 1500 that may be displayed on the consumer device. The consumermay use settings selection 1502 to enable or disable the announcing ofthe payment service.

In some embodiments, the payment service may include one or morebackground processes that may run while the consumer device is locked,in a low-power mode, and/or executing other applications in theforeground. In some embodiments, the one or more broadcasted messagesmay include the wallet identifying data and/or be encrypted using thewallet identifying data.

At 1306, the merchant device may begin discovering the payment service.For example, a process and/or application may execute on the merchantdevice that configures the merchant device to discover other devices,such as the consumer device, that are currently announcing the paymentservice.

In some embodiments, the consumer device may be configured to discoverthe payment service while the merchant device may be configured toannounce the payment service. Additionally and/or alternatively, bothdevices may be configured to be capable of announcing and discoveringthe payment service. For example, both devices may discover compatibledevices and/or be discovered by compatible devices.

At 1308, a connection between the merchant device and the consumerdevice may be created. For example, the consumer device and merchantdevice may come within a certain discovery range (e.g., 10 meters forBluetooth), such as when a consumer carrying the consumer device entersthe merchant's shop. In some embodiments, the discovery range may be setby the merchant device and/or the consumer device and/or by the range atwhich the devices can be located from each other and still be able tocommunicate (such as when Bluetooth and/or other direct connect wirelesstechnology is used).

In some embodiments, some or all of the messages used to form theconnection between the consumer device and the merchant device at1304-1308 may be encrypted and/or signed. For example, messages sentfrom the consumer device may be encrypted and/or signed with the walletidentifying data. Additionally and/or alternatively, messages sent fromthe merchant device may be encrypted and/or signed with merchantidentifying data.

At 1310, the consumer device may send the wallet identifying data to themerchant device. In some embodiments, the consumer device may send theconsumer's name, URL for accessing the image data representing a pictureof the consumer (e.g., as associated with the payment account at 210 ofmethod 200), the image data itself, and/or other suitable consumeridentification information. As discussed above, the wallet identifyingdata may include a wallet identifying token. For example, at least oneof the wallet identifying tokens that the consumer devices received fromthe payment system at 1302 may be sent to the merchant device at 1310.

In some embodiments, the wallet identifying data may include and/orprovide a reference to consumer data stored in the one or moredatabases. As such, the wallet identifying data may be sent to themerchant device in place of actual consumer data that may be readilystolen by an unauthorized device. In some embodiments, the consumerdevice may send the consumer's name, the image data (or URL) and/or apayment account identifier (e.g., as used by payment system 2402) to themerchant device without including and/or using any wallet identifyingdata at 1310.

At 1312, the merchant device may send merchant data to the consumerdevice. For example, the merchant data may include merchant identifyingdata, or other data, that indicates the merchant's identity to theconsumer device. The merchant data may further include information aboutthe merchant, such as items for sale (e.g., products, services, etc.),promotional offerings, sales, etc. FIG. 16 shows an example merchantmain display 1600, in accordance with some embodiments. Merchant maindisplay 1600 may be shown on the consumer device at 1312 and may includethe merchant data, such as merchant name at 1602, deals at 1604, anditems at 1606.

Additionally and/or alternatively, the consumer device may accessmerchant main display 1600 and/or its data via the payment system. Forexample, some or all of the merchant data may be stored in paymentdatabase 2402 and provided to consumer device 2412 via payment server2406 and network 2408, as shown in FIG. 24. A consumer may search and/orbrowse a list for merchants (e.g., using search field 1504 of paymentservice menu display 1500). Upon selecting a particular merchant, amerchant main display 1600 for the merchant may be shown on the consumerdevice.

In some embodiments, the merchant data sent from the merchant device at1312 may include identification data but no additional merchantinformation. As such, the consumer device may be configured to requestthe additional information from the payment system based on theidentification data.

At 1314, the merchant device may be configured to establish a secureconnection with the payment system (e.g., via network 2408 shown in FIG.24). For example, a merchant may provide login data to the paymentsystem that may be used to identify and authenticate the merchant. Thediscussion above regarding payment accounts for consumers may beapplicable to merchant accounts. In that sense, displays may be providedto a merchant device for accessing, managing and/or creating a paymentaccount configured to receive payments. The secure connection with thepayment system may be established at any suitable time, such as beforethe merchant device has connected with the consumer device at 1308. Forexample, the merchant device may include an Internet connection to thepayment system that is active in the course of merchant deviceoperation.

At 1316, the merchant device may be configured to send the walletidentifying data received from the consumer device at 1310 to thepayment system. For example, the wallet identifying data may be sent viathe secure connection established at 1314. As discussed above, thewallet identifying data may include data that identifies the consumerand/or the payment account associated with the consumer. In someembodiments, the wallet identifying data may be a wallet identifyingtoken. Here, the associated private key is not sent with the walletidentifying token.

At 1318, the payment system may be configured to validate the consumer,such as by using the wallet identifying data. For example, the paymentsystem may determine whether the wallet identifying data sent to theconsumer device at 1302 matches or otherwise corresponds with the walletidentifying data received from the merchant device at 1316. For example,the payment system may ensure that the wallet identifying data receivedfrom the merchant device at 1316 originated from the consumer device(e.g., at 1310) that is authorized to use the payment account.Additionally and/or alternatively, the payment system may further beconfigured to extract some or all of the consumer information (e.g., theconsumer's identity) from the wallet identifying data (e.g., by using aprivate key that correspond with a wallet identifying token).

At 1320, the payment system may be configured to send consumerinformation and/or other types of consumer identifying data to themerchant device. In some embodiments, the consumer information may bestored in one or more databases (e.g., payment database 2402). Thepayment system may be configured to request the consumer informationbased on the wallet identifying data received from the merchant deviceat 1316. The consumer information may include, for example, image datarepresenting a picture of the consumer, payment account data, thirdparty account data, purchase history data, user profile data, socialnetwork data, consumer preference data, etc.

FIG. 23 shows an example consumer information display 2300 that may beshown on the merchant device, in accordance with some embodiments.Consumer information display 2300 may be configured to notify themerchant that a compatible consumer device has been discovered andconnected (e.g., at 1304-1308 of method 1300), to provide informationabout consumers for facilitating customer service, and/or to providepoint-of-sale (POS) functionality. In some embodiments, a notificationmay also be shown on the merchant device at 1308 to indicate that aconsumer has entered the vicinity of the merchant device (e.g., enteredinto communicable range) and/or merchant shop.

Consumer entry 2302 may include a display of consumer name at 2304,consumer image at 2306, recommended/favorite items at 2308, preferenceinformation at 2310, visit count at 2312, and/or promotionaldeals/rewards at 2314. Virtually any consumer information associatedwith the payment account may be shown in consumer information display2300. In some embodiments, the consumer device may be configured toallow the consumer to set what consumer information is available to themerchant. Additionally and/or alternatively, the merchant device may beconfigured to allow the merchant to set the types of consumerinformation that is shown in consumer information display 2300.

In some embodiments, consumers may be listed in consumer informationdisplay 2300 based on the proximity of consumer devices to the merchantdevice. Consumers that are associated with consumer devices that arecloser to the merchant device, for example, may be shown near the top ofconsumer information display 2300, or may otherwise be more readilyaccessible via consumer information display 2300, than consumersassociated with consumer devices that are further from the merchantdevice. For example, consumer devices may further include locationtracking and/or location sharing capability. For example, the merchantdevice can be configured to enable the merchant to show and/or hidevarious consumer information based on the proximity of the consumerdevice to the merchant device (using, e.g., real time locating systemfunctionality, received signal strength indication, travel-timelocating, and/or any other suitable proximity determiningfunctionality).

At 1322, the merchant device may be configured to receive productidentifying data for one or more items (e.g., products, services, etc.).The product identifying data may further include price data for the oneor more items. For example, the merchant may select a consumer fromconsumer information display 2300, which may allow the merchant toassociate the one or more items with the consumer to generate a shoppinglist. As will be discussed below in greater detail, the merchant devicemay be a point-of-sale (POS) device that is configured to receive theproduct identifying data. As such, the items may be entered to themerchant device in any suitable way including via barcode scan,radio-frequency identification (RFID), merchant input via a selectablemenu, etc.

At 1324, the merchant device may be configured to send a total cost forthe one or more items to the consumer device. As such, the merchantdevice may be further configured to generate a total cost for the one ormore items. For example, the merchant device may be configured togenerate a sum based on the price data for each item. The merchantdevice may also add costs (e.g., service costs, tips, taxes, warranties,or the like) and/or deduct costs (e.g., deal vouchers, rewards,discounts, sales, store credits, promotions, etc.) from the sum togenerate the total cost. The total cost, as well as the productidentifying data, may then be sent to the consumer device for paymentapproval at 1324. In some embodiments, the total cost may be part oftransaction data that also includes a transaction ID (a unique number orcode generated by the merchant device for each transaction) and/or amerchant ID (a unique number or code associated with each merchant orpeer),

In some embodiments, the merchant device may be configured to allowentry of the total cost. For example, rather than receiving the productidentifying data and determining a total cost, the merchant device mayallow the merchant to simply enter a total cost and send the total costto the consumer device at 1324.

In some embodiments, the merchant device may be configured to allow themerchant to select from a plurality of payment types. For example, themerchant may ask the consumer how the consumer would like to pay. Theconsumer may decide, for example, to pay by cash, credit card, orotherwise without using the consumer device. As such, the merchantdevice may be configured to accept alternative forms of payment. If theconsumer decides to pay via the consumer device, the merchant may soindicate by selecting a selection on the merchant device, which maycause the merchant device to send the total cost to the consumer deviceat 1324.

Additionally and/or alternatively, the one or more items may be enteredby the consumer device. For example, a consumer may browse themerchant's shop and scan items (e.g., via an image capturing device,barcode scanner, etc.) using the consumer device to build the shoppinglist. In some embodiments, the consumer device may be configured toallow the consumer to create the shopping list via the Internet (e.g.,online shopping via merchant main display 1600), at the merchant via theconsumer device, and/or at locations remote from the merchant. Theconsumer device may then send the one or more items in the shopping tothe merchant device and receive the total cost in response.Alternatively and/or additionally, the consumer device may be configuredto calculate the total cost.

In some embodiments, the consumer device may be configured to include alocation tracking device and/or otherwise make its location known to themerchant device and/or the payment system (e.g., payment server 2406, apromotional server, etc.) while the consumer is in the merchant's shop.Advertisements, sales, promotions, or the like may be sent to theconsumer device based on its location. For example, when the consumerdevice is browsing in a section for refrigerators, one or more offersrelated to refrigerators may be provided to the consumer device. Inaddition to offers, the consumer device may be configured to requestassistance and/or information regarding potential purchases.

At 1326, the consumer device may be configured to determine whether toapprove payment. In some embodiments, approving the payment may includegenerating an indication of approval. FIG. 17 shows an example orderapproval display 1700 that may be shown on the consumer device. Orderapproval display 1700 may include sub-total display 1702, tip display1704, tax display 1706 and total amount display 1708. Furthermore, theconsumer may select shopping list selection 1714 to view a listing ofitems (e.g., the one or more items whose price data provides a basis forthe sub-total).

In some embodiments, the consumer device may be configured to allow theconsumer to select a tip amount. For example, the consumer may select atip percentage using tip selection 1710. Responsive to a tip selection,tip display 1706 and total amount display 1708 may be updated to reflectthe new tip and total amounts. In some embodiments, the consumer devicemay allow the consumer to enter a tip amount. As such, a consumer maytip a merchant for service regardless of whether the consumer makes apurchase. For example, a consumer may browse goods at a store and makethe purchase online. If the consumer received assistance from amerchant, the consumer may send a tip amount via the consumer device forthe service. Furthermore, if the consumer has associated a plurality ofpayment sources with the payment account, the consumer device mayfurther be configured to allow the consumer to select a particularpayment source.

If the consumer is satisfied with the payment, the consumer may selectapprove payment selection 1712. In some embodiments, selecting approvalpayment selection 1712 may indicate approval of the payment.Additionally and/or alternatively, the consumer device may allow theuser to provide an additional indication of consent. For example, theconsumer may be prompted to select a box (e.g., a checkbox thatindicates consent), provide login data, generate a signature (e.g., viaa touch sensitive device such as a touch sensor), enter a pin number,and/or provide a biometric identifier (e.g., a fingerprint, voicemessage, retina scan, behavioral identifier, etc.). If the consumer isnot satisfied with the total amount or otherwise does not approve of thepayment, the consumer may select cancel order selection 1716.

Returning to FIG. 13, the consumer device may be configured to sendconsumer approval data secured with wallet identifying data to themerchant device at 1328. The consumer approval data may provide anindication as to whether the consumer has approved the payment. Asdiscussed above, some or all of the messages sent from the consumerdevice may be signed and/or encrypted with the wallet identifying data.For example, the consumer approval data may be sent to the merchantdevice with the wallet identifying data (e.g., as a signature) and/or beencrypted using the wallet identifying data.

In some embodiments, the consumer approval data may include one or moremessages that may include consumer data (e.g., consumer name, paymentsource information, payment account identification, etc.), transactiondata (e.g., total amount, time of transaction, location, etc.), and/orthe additional indication of consent. For example, a message may beformatted with JavaScript Object Notation (JSON), where each piece ofdata is associated with a field. In one embodiment, the consumerapproval data may consist of an electronic signature created byappending a private key to a data string representing the transactiondata and then performing an algorithmic transformation, such as a oneway hash of the private key appended data string (e.g., using acryptographic hash functions such as SHA-1).

In some embodiments, a message (hashed, signed, or otherwise) may beencrypted using the wallet identifying data. The encrypted message mayalso be stored in the message (e.g., in a field within the JSON format)itself. Additionally and/or alternatively, the message may be signedusing the wallet identifying data (e.g., a private key may be isincluded in the message, such as in a field within the JSON format) andthen encrypted. As such, the consumer approval data may further includethe wallet identifying data that the consumer device received from thepayment server at 1302.

In some embodiments, the wallet identifying data used at 1328 mayinclude a different wallet identifying token and/or private key thanthose used at 1310 and, in some embodiments, the wallet identifying dataused at 1328 may include the same wallet identifying token and/orprivate key used at 1310. In other embodiments, the payment system maysend wallet identifying data that includes a wallet identifying tokenand an associated private key to the consumer device at 1302. As such,the wallet identifying token may be used at 1310 and the private key maybe used at 1328. In some embodiments, each wallet identifying tokenand/or private key may only be used one time (or for only a limitedtime), thus the payment system may be able to identify potentialsecurity problems when a single wallet identifying token and/or privatekey is used in two different messages and/or payments.

In some embodiments, the consumer device may be configured toautomatically approve the payment based on satisfaction of one or moretrigger conditions. The consumer device may be configured to send theapproval/disapproval data and/or wallet identifying to the merchantdevice upon satisfaction of the one or more trigger conditions. Forexample, the consumer device may allow the consumer to automaticallyapprove payments (e.g., without using order approval display 1700).

In some embodiments, the identity of the merchant may serve as a triggercondition for automatic payment. For example, the consumer may beallowed to add one or more merchants to an approved merchant list. Theconsumer device may be configured to automatically send theapproval/disapproval data and/or wallet identifying data to the merchantdevice if the merchant device is associated with a merchant from theapproved merchant list. The merchant list may be stored on the consumerdevice and/or provided to the consumer device via the one or moreservers. In some embodiments, the consumer device may be configured usethe merchant data received from the merchant device at 1312 to determinewhether the merchant is on the approved merchant list.

In some embodiments, the location of the consumer device may serve as atrigger condition for automatic payment. For example, the consumerdevice may be configured allow the consumer to generate the shoppinglist (e.g., by scanning items with the consumer device and/or via themerchant) and simply walk out of the store. The location of the consumerdevice may be tracked such that the approval/disapproval data and/orwallet identifying data are sent to the merchant device at 1328 when theconsumer leaves the merchant, is a certain distance from a merchantdevice, etc.

In some embodiments, the reception of the total cost by the consumerdevice at 1324 may serve as a trigger condition for automatic payment.For example, the consumer device may be configured to send theapproval/disapproval data and/or wallet identifying data immediatelywhen the total cost is received from the merchant device. It isappreciated that combinations of one or more trigger conditions may beused. For example, the consumer device may be configured to send theapproval/disapproval data and/or wallet identifying data to onlymerchants on the approved merchant list upon receiving the total cost.

In some embodiments, the reception of the total cost at 1324 may alsoserve trigger the consumer device to determine whether to provide theautomatic payment. For example, the consumer device may be configured todetermine whether the one or more trigger conditions are satisfied basedon information received from the merchant device (e.g., at 1312 and/or1324).

Other example trigger conditions may include merchant location, merchanttype (e.g., retailers, restaurants, etc.), the total cost amount (e.g.,automatically approve payments below a specified amount), etc.

In some embodiments, the consumer may be allowed to set automaticapprovals on or off. Additionally and/or alternatively, a consumer mayspecify that only certain types of transactions require approval. Inanother example, approval for an initial purchase may be required ateach merchant, but not for subsequent purchases. Similarly, an approvedmerchant may be removed or otherwise set such that the next and/or everytransaction with the merchant needs to be approved.

In some embodiments, the merchant device may be configured to not allowautomatic payment approval based on one or more trigger conditions. Forexample, the merchant device may specify that payments above a certainthreshold amount require manual approval.

At 1330, the merchant device may be configured to send the consumerapproval data secured with the wallet identifying data to the paymentsystem. In some embodiments, the consumer approval data sent by theconsumer device at 1328 may be sent to the payment server without anysubstantial processing and/or decoding by the merchant device. As such,the payment system may be configured to provide a payment service to themerchant device to facilitate financial transactions (e.g., processpayments from the consumer's payment account to a merchant's paymentaccount and/or other financial account). In some embodiments, onlyapproved payments are sent to the payment system. In some embodiments,the merchant may be able to require consumer approval either at alltimes or based on various conditions. For example, the merchant may seta value that requires consumer approval for payments above the setvalue.

In some embodiments, the merchant device may be configured to generatesecure payment approval data based on the consumer approval data andsend the secure payment approval data to the merchant device. The securepayment approval data may include the consumer approval data and thetransaction data (e.g., as may be modified by the consumer at 1418, suchas to add a tip amount to the total cost).

At 1332, the payment system may be configured to validate and/or processthe payment. For example, the payment system may process the walletidentifying data to decode and/or otherwise authenticate the consumerdata, transaction data, and/or the indication of consent sent from themerchant device. Furthermore, the payment system may determine thepayment account, payment source, total amount, or the like based on thereceived and/or extracted transaction data.

In some embodiments, where the consumer approval data consists of anelectronic signature created by appending a private key to a data stringrepresenting the transaction data and then performing an algorithmictransformation, such as a one way hash of the private key appended datastring, the payment system may be configured to validate the payment byrecreating the electronic signature based on the transaction data. Forexample, the transaction data and the consumer approval data may bereceived from the merchant device. Next, the central system may appendthe private key (e.g., as stored in the payment system) to thetransaction data and perform the same algorithmic transformation torecreate the consumer approval data. If the recreated consumer approvaldata matches the received consumer approval data, the payment may bevalidated.

In some embodiments, processing the payment may further includecommunicating with one or more third party servers, such as credit cardservers, bank account servers, and/or any other type of financial serverthat may be suitable to help complete the financial transaction. Forexample, the payment server may send some or all of the transaction datato the one or more third party servers and receive an indication as towhether the financial transaction was successful.

At 1334, the payment system may be configured to send a receipt for thepayment to the consumer device. The receipt may alternatively, and/oradditionally, be sent to merchant device and then sent from the merchantdevice to the consumer device (e.g., when the consumer device does notinclude an active connection to the payment server and/or when thepayment server is otherwise unable to communicate with the consumerdevice).

FIG. 18 shows an example receipt display 1800, in accordance with someembodiments. Receipt display 1800 may be shown on the consumer device toprovide an indication to the consumer that the financial transaction wassuccessfully. As such, receipt display 1800 may include transaction dataat 1802 and payment confirmation display 1804. FIG. 19 shows a receiptnotification display 1900 that may be shown additionally and/oralternatively shown on the consumer device. For example, receiptnotification display 1900 may be shown responsive to the consumer devicereceiving the receipt. Receipt notification display 1900 may includenotification selection 1902 that includes transaction price indicator1904 and merchant indicator 1906. In some embodiments, displaysproviding receipt information (e.g., display 1800 and/or 2000-2200) maybe shown on the consumer device responsive to the consumer selectingnotification selection 1902 to provide more information about thereceipt.

FIG. 20 shows an example receipt listing display 2000, in accordancewith some embodiments. Receipt listing display 2000 may be configured toprovide a listing of receipts associated with the payment account.Receipt listing display 2000 may be accessed, for example, by selectingreceipts selection 1506 in payment service menu display 1500. As shown,a listed receipt (e.g., listed receipt 2002) may include a display ofmerchant image 2004 (e.g., a trademark, symbol, slogan, icon, graphic,photograph, etc.), merchant name 2006, transaction date 2008 and/oramount paid 2010. The receipts may be listed based on virtually anyordering criteria, such as the transaction date or merchant name, insome example embodiments.

In some embodiments, receipts may be searchable. For example, a consumermay enter search criteria (e.g., merchant name or transaction date asshown in FIG. 2000) in receipt search 2012. Responsive to entering thesearch, the consumer device may show a listing of receipts that fit, orcome closest to fitting, the search criteria.

In some embodiments, the listed receipts in receipt listing display 2000may be selectable. Upon selecting a listed receipt, additionalinformation about the receipt may be shown on the consumer device. Forexample, upon selecting listed receipt 2002, the consumer device may beconfigured to show receipt display 2100. The discussion above regardingreceipt display 1800 may be applicable to receipt display 2100. In someembodiments, receipt display 2002 may alternatively and/or additionallyinclude payment source identifier 1806. As shown in FIG. 21, paymentsource identifier 2102 indicates that the payment was made with a creditcard ending having a credit card number ending with 2345 and a 12/15expiration date.

In some embodiments, the consumer device may be configured to allow theconsumer to view items associated with the receipt. For example, theconsumer may select receipt item selection 2104 in receipt display 2100.FIG. 22 shows an example view receipt items display 2200 that includesreceipt items listing 2202. As shown, receipt items listing 2202 mayinclude a list of items and associated price data.

Returning to FIG. 13, the payment system may be configured to send aconfirmation to the merchant device at 1336. For example, theconfirmation may indicate whether the payment was successfullyprocessed. An indication may be shown on the merchant device to alertthe merchant. For example, if the payment was not successful, themerchant may request that the consumer provide an alternate form ofpayment and/or to resubmit the payment via the consumer device.

As discussed above, the techniques disclosed herein may apply not onlyto payments between consumer devices and merchant devices, but to anytype of suitable devices or “peer devices.” For example, a merchant mayuse a first device to pay a second merchant using a second device. Inanother example, a consumer may use a first device to pay a secondconsumer using a second device. In that sense, method 1300 may allow twousers of any kind to access their payment accounts, discover compatibledevices, and/or make payments with each other for any purpose.

FIG. 14 shows a flow chart of an example of a method 1400 of making apayment, performed in accordance with some embodiments. Some of thediscussion above regarding method 1300 may be applicable to method 1400and are not repeated in detail. Method 1400 may allow a first peerdevice to provide a payment to a second peer device. Thus the discussionregarding the first peer device may be applicable to the second peerdevice, and vice versa. Method 1400 may be used among merchants and/orother peer devices, and/or simply when the payee does not have networkaccess to the payment system at the time the transaction occurs with thepayor.

At 1402, the payment system (e.g., payment server 2406 shown in FIG. 24)may be configured to send wallet identifying data to a first peer device(e.g., a consumer device or a merchant device). The wallet identifyingdata may be configured to secure messages sent from the first peerdevice.

At 1404-1408, the first peer device and the second peer device may beconfigured to form a connection. As discussed above regarding method1300 at 1304-1308, the connection may be formed without the first peerdevice and/or the second peer device having active Internet access atthe time of the connection (e.g., an active connection to the one ormore servers). Instead, a personal area network that allows for devicediscovery, or similar techniques, may be used.

At 1410, the first peer device may be configured to send the walletidentifying data to the second peer device. If the second peer devicehas an active connection to the payment system, the wallet identifyingdata may be sent to the payment system and consumer data may be returnedto the second peer device from the payment system after validation, asdiscussed above.

Additionally and/or alternatively, if the second peer device does notinclude the active connection to the payment system, the second peerdevice may be configured to store the wallet identifying data at 1412.In some embodiments, the first peer device may be further configured tosend some or all of the consumer information at 1412 (e.g., as discussedat 1320 of method 1300) to the second peer device. In that sense, someor all of the consumer information may be signed or otherwise securedwith the wallet identifying data. For example, private information suchas payment account data may be secured while basic information (e.g.,name, image data) may be sent without the wallet identifying data.Consumer information that is not secured may be readily accessible bythe second peer device without sending the wallet identifying data tothe payment system for secure retrieval (e.g., as discussed at 1316 ofmethod 1300).

At 1414, the second peer device may be configured to receive productidentifying data for one or more items. The discussion above regarding1322 of method 1300 may be applicable at 1414. For example, the itemsmay be entered into the second peer device and/or be entered into thefirst peer device and then sent to the second peer device. If the itemsare entered by the second peer device, the second peer device may befurther configured to generate a total cost (e.g., based on price data)and to send the total cost to the first peer device at 1416. In anotherexample, the first peer device and/or the second peer device may beallowed to simply enter the total cost and/or select items from avirtual listing.

At 1418, the first peer device may be configured to determine whether toapprove the payment. At 1420, the first peer device may be configured tosend consumer approval data secured with the wallet identifying data tothe second peer device. The discussion above regarding 1326-1328 ofmethod 1300 may be applicable at 1418-1420.

In some embodiments, at least some of the consumer approval data may besent by the first peer device such that the second peer device maydetermine whether the payment was approved without communicating withthe payment system. For example, a message or a part of a message mayinclude an unsecured indication regarding whether the payment isapproved or disapproved that may be understood by the second device.Other data (e.g., consumer data, transaction data, and/or the additionalindication of consent) may be signed or otherwise secured with thewallet identifying data such that the content is accessible only via thepayment system.

At 1422, the consumer approval data secured with the wallet identifyingdata may be stored by the second peer device (or a separate storagedevice that may be accessed by the second peer device). For example, ifthe second peer device does not include an active connection to thepayment system, the second peer device may be configured to store thedata until a connection with the payment system is established.Alternatively and/or additionally, if the second peer device doesinclude an active connection, the second peer device may be configuredto send the consumer approval data (or secured payment approval data, asdiscussed above) to the payment system at 1422.

At 1424, the second peer device may establish a secure connection withthe payment system (e.g., if the secure connection is not alreadyactive). At 1424, the second peer device may send the consumer approvaldata (or secured payment approval data, as discussed above) data to thepayment system. At 1426, the payment system may be configured tovalidate and process the payment. At 1428, the payment system may send areceipt to the first peer device (either directly, or via the secondpeer device). At 1430, the payment system may be configured to send apayment confirmation to the second peer device. The discussion above at1314 and 1320-1326 of method 1300 may be applicable at 1424-1430.

Exemplary System Architecture

FIG. 24 shows system 2400 including an example network architecture,which may include one or more devices and sub-systems that areconfigured to implement some embodiments discussed herein. For example,system 2400 may include payment system 2402, which can include, forexample, payment server 2404 and payment database 2406, among otherthings (not shown). Payment server 2404 may be any suitable networkserver and/or other type of processing device. Payment database 2406 maybe any suitable network database configured to store information such asmerchant and consumer information, login data, payment account data,payment source data, transaction data, and/or wallet identifying data,such as may be used to facilitate payment as discussed herein. In thisregard, system 2402 may include, for example, at least one backend dataserver, network database, cloud computing device, among other things.

Payment system 2402 may be coupled to one or more merchant devices(e.g., merchant device 2410) via network 2408. In this regard, network2408 may include any wired or wireless communication network including,for example, a wired or wireless local area network (LAN), personal areanetwork (PAN), metropolitan area network (MAN), wide area network (WAN),or the like, as well as any hardware, software and/or firmware requiredto implement it (such as, e.g., network routers, etc.). For example,network 2408 may include a cellular telephone, an 802.11, 802.16,802.20, and/or WiMax network. Further, the network 2408 may include apublic network, such as the Internet, a private network, such as anintranet, or combinations thereof, and may utilize a variety ofnetworking protocols now available or later developed including, but notlimited to TCP/IP based networking protocols.

As discussed above, merchant device 2410 may be associated with amerchant, such as a retail store, restaurant, etc. In some embodiments,merchant device 2410 may be a POS device that is configured to receivepayments at the merchant's shop. As such, merchant device 2410 mayinclude a personal computer and/or other networked device, such as acellular phone, tablet computer, mobile device, etc., that may be usedfor any suitable purpose in addition to providing point-of-salefunctionality at the restaurant. Accordingly, display 2300 may beprovided to a merchant by a POS device.

System 2400 may further include one or more consumer devices (e.g.,consumer device 2412). As shown in FIG. 33, consumer device 2412 mayconnect with merchant device 2410 via network 2408 and/or PAN network2416. As such, consumer device 2412 may be configured to make paymentswith merchant device 2410 via PAN network 2416 even if consumer device2412 and/or merchant device 2410 do not have active connections withnetwork 2408.

In some embodiments, system 2400 may further include one or more thirdparty systems (e.g., third party system 2414), among other things. Insome embodiments, different third party systems may be associated withdifferent types of payment sources. Thus for each payment source, datamay be sent to an appropriate third party system (e.g., a credit cardtransaction server, etc.) to validate and/or process payments.

In some embodiments, the payment system 2400 may be a multi-tenantdatabase system configured to provide payment services to a plurality ofconsumers and merchants. Additionally and/or alternatively, paymentsystem 2400 may be configured to include, or work in connection with,online ordering systems (e.g., shop online and pickup), promotionalsystems (e.g., deal voucher accounts, offerings, purchases, andredemptions, where the value of a redeemed voucher may be deducted fromthe payment), merchant systems (e.g., kitchen systems for restaurants),and/or appointment systems (e.g., scheduling a reservation at arestaurant). It is appreciated that the payment techniques disclosedherein may be applicable to any environment that involves financialtransactions.

FIG. 25 shows a schematic block diagram of circuitry 2500, some or allof which may be included in, for example, payment system 2404, consumerdevice 2412, and/or merchant device 2410. As illustrated in FIG. 25, inaccordance with some example embodiments, circuitry 2500 may includevarious means, such as one or more processors 2502, memories 2504,communications modules 2506, and/or input/output modules 2508.

In some embodiments, such as when circuitry 2500 is included in merchantdevice 2410 and/or payment system 2402, payment/redemption module 2510may also or instead be included. As referred to herein, “module”includes hardware, software and/or firmware configured to perform one ormore particular functions. In this regard, the means of circuitry 2500as described herein may be embodied as, for example, circuitry, hardwareelements (e.g., a suitably programmed processor, combinational logiccircuit, and/or the like), a computer program product comprisingcomputer-readable program instructions stored on a non-transitorycomputer-readable medium (e.g., memory 2504) that is executable by asuitably configured processing device (e.g., processor 2502), or somecombination thereof.

Processor 2502 may, for example, be embodied as various means includingone or more microprocessors with accompanying digital signalprocessor(s), one or more processor(s) without an accompanying digitalsignal processor, one or more coprocessors, one or more multi-coreprocessors, one or more controllers, processing circuitry, one or morecomputers, various other processing elements including integratedcircuits such as, for example, an ASIC (application specific integratedcircuit) or FPGA (field programmable gate array), or some combinationthereof. Accordingly, although illustrated in FIG. 25 as a singleprocessor, in some embodiments, processor 2502 comprises a plurality ofprocessors. The plurality of processors may be embodied on a singlecomputing device or may be distributed across a plurality of computingdevices collectively configured to function as circuitry 2500. Theplurality of processors may be in operative communication with eachother and may be collectively configured to perform one or morefunctionalities of circuitry 2500 as described herein. In an exampleembodiment, processor 2502 is configured to execute instructions storedin memory 2504 or otherwise accessible to processor 2502. Theseinstructions, when executed by processor 2502, may cause circuitry 2500to perform one or more of the functionalities of circuitry 2500 asdescribed herein.

Whether configured by hardware, firmware/software methods, or by acombination thereof, processor 2502 may comprise an entity capable ofperforming operations according to embodiments of the present inventionwhile configured accordingly. Thus, for example, when processor 2502 isembodied as an ASIC, FPGA or the like, processor 2502 may comprisespecifically configured hardware for conducting one or more operationsdescribed herein. As another example, when processor 2502 is embodied asan executor of instructions, such as may be stored in memory 2504, theinstructions may specifically configure processor 2502 to perform one ormore algorithms and operations described herein, such as those discussedin connection with FIGS. 1, 2, 13 and 14.

Memory 2504 may comprise, for example, volatile memory, non-volatilememory, or some combination thereof. Although illustrated in FIG. 25 asa single memory, memory 2504 may comprise a plurality of memorycomponents. The plurality of memory components may be embodied on asingle computing device or distributed across a plurality of computingdevices. In various embodiments, memory 2504 may comprise, for example,a hard disk, random access memory, cache memory, flash memory, a compactdisc read only memory (CD-ROM), digital versatile disc read only memory(DVD-ROM), an optical disc, circuitry configured to store information,or some combination thereof. Memory 2504 may be configured to storeinformation, data (including deal parameter data and/or analytics data),applications, instructions, or the like for enabling circuitry 2500 tocarry out various functions in accordance with example embodiments ofthe present invention. For example, in at least some embodiments, memory2504 is configured to buffer input data for processing by processor2502. Additionally or alternatively, in at least some embodiments,memory 2504 is configured to store program instructions for execution byprocessor 2502. Memory 2504 may store information in the form of staticand/or dynamic information. This stored information may be stored and/orused by circuitry 2500 during the course of performing itsfunctionalities.

Communications module 2506 may be embodied as any device or meansembodied in circuitry, hardware, a computer program product comprisingcomputer readable program instructions stored on a computer readablemedium (e.g., memory 2504) and executed by a processing device (e.g.,processor 2502), or a combination thereof that is configured to receiveand/or transmit data from/to another device, such as, for example, asecond circuitry 2500 and/or the like. In some embodiments,communications module 2506 (like other components discussed herein) canbe at least partially embodied as or otherwise controlled by processor2502. In this regard, communications module 2506 may be in communicationwith processor 2502, such as via a bus. Communications module 2506 mayinclude, for example, an antenna, a transmitter, a receiver, atransceiver, network interface card and/or supporting hardware and/orfirmware/software for enabling communications with another computingdevice. Communications module 2506 may be configured to receive and/ortransmit any data that may be stored by memory 2504 using any protocolthat may be used for communications between computing devices.Communications module 2506 may additionally or alternatively be incommunication with the memory 2504, input/output module 2508 and/or anyother component of circuitry 2500, such as via a bus.

Input/output module 2508 may be in communication with processor 2502 toreceive an indication of a user input and/or to provide an audible,visual, mechanical, or other output to a user (e.g., merchant and/orconsumer). Some example visual outputs that may be provided to a user bycircuitry 2500 are discussed in connection with FIGS. 3-12 and 15-23. Assuch, input/output module 2508 may include support, for example, for akeyboard, a mouse, a joystick, a display, an image capturing device, atouch screen display, a microphone, a speaker, a RFID reader, barcodereader, biometric scanner, and/or other input/output mechanisms. Inembodiments wherein circuitry 2500 is embodied as a server or database,aspects of input/output module 2508 may be reduced as compared toembodiments where circuitry 2500 is implemented as an end-user machine(e.g., consumer device and/or merchant device) or other type of devicedesigned for complex user interactions. In some embodiments (like othercomponents discussed herein), input/output module 2508 may even beeliminated from circuitry 2500. Alternatively, such as in embodimentswherein circuitry 2500 is embodied as a server or database, at leastsome aspects of input/output module 2508 may be embodied on an apparatusused by a user that is in communication with circuitry 2500, such as forexample, merchant device 2410 and/or consumer device 2412. Input/outputmodule 2508 may be in communication with memory 2504, communicationsmodule 2506, and/or any other component(s), such as via a bus. Althoughmore than one input/output module and/or other component can be includedin circuitry 2500, only one is shown in FIG. 25 to avoidovercomplicating the drawing (like the other components discussedherein).

Payment/redemption module 2510 may also or instead be included andconfigured to perform the functionality discussed herein related tofacilitating payment transactions discussed above. In some embodiments,some or all of the functionality facilitating payment transactions maybe performed by processor 2502. In this regard, the example processesand algorithms discussed herein can be performed by at least oneprocessor 2502 and/or payment/redemption module 2510. For example,non-transitory computer readable storage media can be configured tostore firmware, one or more application programs, and/or other software,which include instructions and other computer-readable program codeportions that can be executed to control each processor (e.g., processor2502 and/or payment/redemption module 2510) of the components of system2500 to implement various operations, including the examples shownabove. As such, a series of computer-readable program code portions areembodied in one or more computer program products and can be used, witha computing device, server, and/or other programmable apparatus, toproduce machine-implemented processes.

As will be appreciated, any such computer program instructions and/orother type of code may be loaded onto a computer, processor or otherprogrammable apparatus's circuitry to produce a machine, such that thecomputer, processor other programmable circuitry that execute the codeon the machine create the means for implementing various functions,including those described herein.

It is also noted that all or some of the information presented by theexample displays discussed herein can be based on data that is received,generated and/or maintained by one or more components of system 2500. Insome embodiments, one or more external systems (such as a remote cloudcomputing and/or data storage system) may also be leveraged to provideat least some of the functionality discussed herein.

As described above and as will be appreciated based on this disclosure,embodiments of the present invention may be configured as methods,mobile devices, backend network devices, and the like. Accordingly,embodiments may comprise various means including entirely of hardware orany combination of software and hardware. Furthermore, embodiments maytake the form of a computer program product on at least onenon-transitory computer-readable storage medium having computer-readableprogram instructions (e.g., computer software) embodied in the storagemedium. Any suitable computer-readable storage medium may be utilizedincluding non-transitory hard disks, CD-ROMs, flash memory, opticalstorage devices, or magnetic storage devices.

Embodiments of the present invention have been described above withreference to block diagrams and flowchart illustrations of methods,apparatuses, systems and computer program products. It will beunderstood that each block of the circuit diagrams and processflowcharts, and combinations of blocks in the circuit diagrams andprocess flowcharts, respectively, can be implemented by various meansincluding computer program instructions. These computer programinstructions may be loaded onto a general purpose computer, specialpurpose computer, or other programmable data processing apparatus, suchas processor 2502 and/or deal payment/redemption module 2510 discussedabove with reference to FIG. 25, to produce a machine, such that thecomputer program product includes the instructions which execute on thecomputer or other programmable data processing apparatus create a meansfor implementing the functions specified in the flowchart block orblocks.

These computer program instructions may also be stored in acomputer-readable storage medium (e.g., memory 2504) that can direct acomputer or other programmable data processing apparatus to function ina particular manner, such that the instructions stored in thecomputer-readable storage medium produce an article of manufactureincluding computer-readable instructions for implementing the functiondiscussed herein. The computer program instructions may also be loadedonto a computer or other programmable data processing apparatus to causea series of operational steps to be performed on the computer or otherprogrammable apparatus to produce a computer-implemented process suchthat the instructions that execute on the computer or other programmableapparatus provide steps for implementing the functions discussed herein.

Accordingly, blocks of the block diagrams and flowchart illustrationssupport combinations of means for performing the specified functions,combinations of steps for performing the specified functions and programinstruction means for performing the specified functions. It will alsobe understood that each block/step of the circuit diagrams and processflowcharts, and combinations of blocks/steps in the circuit diagrams andprocess flowcharts, can be implemented by special purpose hardware-basedcomputer systems that perform the specified functions or steps, orcombinations of special purpose hardware and computer instructions.

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which theseembodiments of the invention pertain having the benefit of the teachingspresented in the foregoing descriptions and the associated drawings. Forexample, although the examples discussed herein do not require theconsumer to present a form of payment (such as a credit card) to themerchant, some embodiments of the merchant device can be configured towork with one or more peripheral devices that can receive paymentinformation directly from a consumer (such as a credit card reader,radio frequency identification reader, etc.) in addition to or insteadof from the payment server. Therefore, it is to be understood that theembodiments of the invention are not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

1. A merchant device comprising: a display configured to present interactive displays; communications circuitry configured to facilitate communications with a consumer device and a payment server; and processing circuitry configured to: wirelessly send a total cost to the consumer device; wirelessly receive consumer approval data for a payment from the consumer device, wherein the consumer approval data is secured with wallet identifying data; and send the consumer approval data to the payment system.
 2. The merchant device of claim 1, wherein the processing circuitry is further configured to: receive a payment confirmation indicating payment of the total cost from a payment account associated with the consumer device; and send a receipt indicating payment of the total cost to the consumer device.
 3. The merchant device of claim 1, wherein the processing circuitry is further configured to receive, from the payment system, consumer identifying data associated with the wallet identifying data.
 4. The merchant device of claim 1, wherein the processing circuitry is further configured to: receive product identifying data, wherein price data is associated with the product identifying data; and determine the total cost based on the price data.
 5. The merchant device of claim 1, wherein the wallet identifying data is based at least partially on a random code generated by the payment system.
 6. The merchant device of claim 1, wherein the processing circuitry is further configured to receive image data representing a picture of a consumer associated with the consumer device.
 7. (canceled)
 8. The merchant device of claim 6, wherein the processing circuitry system is further configured to receive the image data prior to sending the total cost to the consumer device.
 9. (canceled)
 10. The merchant device of claim 1, wherein the wallet identifying data includes one or more tokens.
 11. The merchant device of claim 1, wherein the processing circuitry is further configured to establish a connection with the consumer device via a personal area network.
 12. The merchant device of claim 11, wherein the personal area network is configured to communicate via one or more Bluetooth protocols.
 13. The merchant device of claim 11, wherein the merchant device is further configured to wirelessly receive the consumer approval data secured with the wallet identifying data from the consumer device over the personal area network even when the merchant device lacks Internet access and is unable to connect to the payment system. 14-17. (canceled)
 18. A machine-implemented method of receiving a payment, comprising: determining, by circuitry, a total cost associated with a payment transaction; wirelessly sending, by the circuitry, the total cost to a consumer device; wirelessly receiving, by the circuitry, consumer approval data from the consumer device, wherein the consumer approval data is secured with wallet identifying data; sending, by the circuitry, the consumer approval data secured with the wallet identifying data to a payment system; and receiving, by the circuitry, a payment confirmation indicating payment of the total cost from the payment system.
 19. The method of claim 18 further comprising receiving, from the payment system, consumer identifying data associated with the wallet identifying data.
 20. The method of claim 18 further comprising: receiving product identifying data associated with the consumer device, wherein price data is associated with the product identifying data; and determining the total cost based on the price data.
 21. The method of claim 18, wherein the wallet identifying data is based at least partially on a random code generated by the payment system.
 22. The method of claim 18, wherein the consumer identifying data includes image data representing a picture of a consumer.
 23. (canceled)
 24. The method of claim 18, wherein the wallet identifying data includes one or more tokens.
 25. The method of claim 18 further comprising establishing a connection with the consumer device via a personal area network.
 26. The method of claim 25, wherein the personal area network is configured to communicate via a Bluetooth protocol.
 27. The method of claim 18 further comprising establishing a connection with the consumer device when the consumer device and the merchant device are separated by a predetermined distance.
 28. (canceled)
 29. (canceled)
 30. A machine-implemented method of facilitating a payment, comprising: sending, by circuitry, wallet identifying data to a consumer device; receiving, by the circuitry, consumer approval data associated with a payment from a merchant device, wherein the consumer approval data is secured with wallet identifying data; validating, by the circuitry, the consumer approval data received from the merchant device; and processing, by the circuitry, the payment after validating the consumer approval data received from the merchant device.
 31. The method of claim 30 further comprising: receiving consumer identifying data from the consumer device; receiving payment account information from the consumer device; and generating the wallet identifying data associated with the payment account information and the consumer identifying data.
 32. The method of claim 31 further comprising sending the consumer identifying data to the merchant device after validating the wallet identifying data.
 33. The method of claim 30 further comprising sending a payment confirmation indicating payment of the total cost to the merchant device after processing the payment.
 34. The method of claim 30 further comprising sending a receipt indicating payment of the total cost to the consumer device after processing the payment.
 35. The method of claim 30 further comprising: generating random code; and generating the wallet identifying data based at least partially on the random code.
 36. A payment system comprising: a networked device comprising: communications circuitry configured to facilitate communications with a consumer device and a merchant device; and processing circuitry configured to: send wallet identifying data to a consumer device; receive consumer approval data associated with a payment from a merchant device, wherein the consumer approval data is secured with the wallet identifying data; validate the consumer approval data received from the merchant device; and process the payment after validating the consumer approval data received from the merchant device.
 37. The system of claim 36, wherein the processing circuitry is further configured to: receive consumer identifying data from the consumer device; receive payment account information from the consumer device; and generate the wallet identifying data associated with the payment account information and the consumer identifying data.
 38. The system of claim 37, wherein the processing circuitry is further configured to send the consumer identifying data to the merchant device after validating the wallet identifying data.
 39. (canceled)
 40. (canceled)
 41. The system of claim 36, wherein the processing circuitry is further configured to: generate random code; and generate the wallet identifying data based at least partially on the random code.
 42. (canceled)
 43. (canceled)
 44. The merchant device of claim 5, wherein the consumer approval data is secured with the wallet identifying data by the consumer device.
 45. The method of claim 21, wherein the consumer approval data is secured with the wallet identifying data by the consumer device 